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Building  Distributed  Ada  Applications  from 
Specifications  and  Functional  Components 


Abstract:  Durra  is  a  language  and  support  environment  for  the  specification 
and  execution  of  distributed  Ada  applications.  A  Durra  programmer  describes 
an  application  as  a  collection  of  processes  and  data  links.  More  complicated 
application  descriptions  may  also  include  a  structuring  of  this  collection  that 
varies  dynamically  according  to  a  set  of  reconfiguration  conditions.  Each 
process  defined  in  the  application  description  is  associated  with  an 
independently  compiled  Ada  subprogram  that  implements  the  behavior  of  that 
process.  The  Durra  programmer  specifies  the  distribution  of  application 
components  by  assigning  them  to  virtual  nodes  called  dusters.  For  each 
cluster,  the  Durra  compiler  generates  a  multithreaded  Ada  program  that 
imports  the  code  for  the  processes  assigned  to  that  node  and  manages  their 
execution.  Durra  also  facilitates  rapid  prototyping  through  the  use  of  tools  that 
interpret  timing  specifications  associated  with  processes  and  generate  Ada 
code  to  simulate  their  expected  behavior. 


1  Motivation 

Computing  environments  consisting  of  loosely  connected  networks  of  special  and  general  pur¬ 
pose  processors  are  becoming  commonplace.  The  corresponding  trend  in  software  is  away 
from  sequential  programs  running  on  large  uniprocessor  hardware  toward  concurrent  pro¬ 
grams  distributed  across  multiple,  possibly  heterogeneous,  platforms.  Today,  developers  of 
such  applications  typically  “hard  code”  the  allocation  of  computing  resources  into  their  appli¬ 
cations  by  explicitly  assigning  specific  tasks  to  run  on  specific  processors  at  specific  times. 
The  component  tasks  of  such  an  application  require  built-in  knowledge  about  the  structure  of 
the  application  and  the  allocation  of  resources  in  order  to  communicate  with  other  tasks.  This 
coupling  of  function  to  structure  complicates  modification  of  the  application,  poses  obstacles 
to  runtime  changes  in  the  application  structure,  and  prevents  reuse  of  the  tasks  in  other  envi¬ 
ronments.  Developers  new  tools  that  allow  them  to  abstract  application  structure  from  func¬ 
tion. 

In  this  paper  we  describe  Durra,  a  language  and  support  environment  for  the  specification  and 
execution  of  distributed  Ada  applications^ 


An  earlier  version  of  this  paper  was  presented  at  TRI-Ada'91,  San  Jose,  California,  October  22-25,  1991.  and 
appears  in  the  conference  proceedings. 
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2  Introduction  to  Durra 


2.1  The  Durra  Language 

Durra  [1]  is  a  task-level  application  description  language.^  The  basic  building  blocks  of  the  lan¬ 
guage  are  the  task  description,  which  specifies  the  properties  of  an  associated  subprogram  or 
subsystem,  and  the  channel  description,  which  specifies  the  properties  of  an  Ada  package  im¬ 
plementing  a  communication  facility.  See  Figure  2-1  for  a  Durra  task  description  template. 
Task  descriptions  may  be  either  primitive  or  compound.  A  primitive  task  description  represents 
a  single  thread  of  control.^  A  compound  task  description  is  a  composition  of  other  task  and 
channel  descriptions.  Channel  descriptions  are  syntactically  similar  to  primitive  task  descrip¬ 
tions  although  the  implementations  exhibit  different  behaviors.  Task  implementations  are  ac¬ 
tive  components;  they  initiate  requests  to  send  or  receive  messages  by  calling  procedures  pro¬ 
vided  by  the  runtime  environment.  Channel  implementations  are  passive  components;  they 
wait  for  and  respond  to  requests  from  the  runtime  environment.  Task  and  channel  implemen¬ 
tations  are  “black  boxes,”  i.e.,  the  internal  workings  of  a  component  are  not  a  consideration  in 
the  construction  of  a  Durra  application. 

A  Durra  programmer  desaibes  an  application  as  a  collection  ot  processes  (instances  of  Durra 
task  descriptions)  connected  to  each  other  in  a  graph  structure  via  links  (instances  of  channel 
descriptions).  Lower  level  components  are  used  as  building  blocks  for  higher  level  task  de¬ 
scriptions.  Application  descriptions  are  simply  compound  task  descriptions  that  describe  a 
complete  application. 

A  component’s  input/output  interface  is  specified  by  the  ports  section  (see  Figure  2-1)  of  its 
description.  Ports  are  named,  unidirectional,  locally-defined  conduits  through  which  processes 
may  transmit/receive  data.  Ports  have  a  Durra  data  type  associated  with  them  to  allow  seman¬ 
tic  checking  of  intercomponent  port  connections. 

Durra  data  type  declarations  define  either  a  size  type  or  a  union  type.  A  size  type  declaration 
associates  an  identifier  with  a  data  size  (or  a  range  of  data  sizes)  expressed  in  bits.  A  union 
type  declaration  defines  a  new  type  as  the  union  of  one  or  more  previously  declared  types. 
This  type  concept  is  analogous  to  our  "black  box”  treatment  of  tasks-no  semantic  information 
other  than  the  type  name  and  the  size  of  the  data  is  derived  from  a  type  declaration.  Here  are 
some  examples  of  Durra  type  declarations; 

type  byt*  Is  size  8; 

type  scalar  Is  Size  4*8lsao£  (byta)  ; 

type  aassaga  Is  union  (byta,  scalar); 


^  Throughout  this  document,  the  term  task  refers  to  a  generalized  thread  of  control’  concept  rather  than  to  the 
analogous  Ada  construct,  except  where  noted. 

^  The  actual  Ada  code  that  implements  a  Durra  task  may,  in  fact,  be  a  multitasking  program.  However,  from  the 
Durra  perspective  the  program  is  a  single  thread  of  control. 
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bask  taskname  (parameter-list ) 

—  Values  for  the  parameters  are  provided  in  task  selections 

ports 

port -declarations 

—  A  description  of  the  input-output  interface  of  the  task 

behavior 

specification-list 

—  Labelled  formal  specifications  of  the  behavior  of  the  task 

attributes 

attribute-value-pairs 

—  A  list  of  additional  properties  of  the  task 
components  — (for  compound  tasks  only) 
component -declarations 

—  A  list  of  task  and  channel  selections 
structures  — (for  compound  tasks  only) 
co/rgsonent -connect  ion -structure 
—  A  list  of  component  connections 
reconfigurations  — (for  compound  tasks  only) 
condition-transit ion -pairs 
—  A  list  of  conditional  structure  changes 
clusters  — (for  compound  tasks  only) 
cluster-component -associations 

—  A  list  of  named  physical  groupings  of  components 
and  taskname; 

Figure  2-1 :  A  Template  for  Task  Descriptions 

The  behsvior  section  of  the  component  description  includes  zero  or  more  formal  specifications 
of  the  behavior  of  the  component’s  actual  implementation.  These  specifications  are  not  inter¬ 
preted  by  the  Durra  compiler  directly,  but  by  associated  tools.  Although  behavioral  specifica¬ 
tions  are  not  part  of  the  Durra  language,  a  Durra  component  description  provides  a  convenient 
placeholder  for  such  specifications.  Component  descriptions  containing  behavioral  specifica¬ 
tions  may  then  be  used  as  components  of  an  application  description.  A  specification  analysis 
tool  is  thus  provided  with  a  framework  for  reasoning  about  the  composition  of  the  specifica¬ 
tions  within  an  application  architecture. 

The  attributes  section  defines  additional  properties  of  the  component,  such  as  version  number 
or  type  of  processor  required.  A  primitive  task  description  must  be  associated  (via  an  attribute 
value)  with  a  specific  Ada  procedure  that  is  its  implementation. 
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Figure  2-2  is  an  example  of  a  primitive  Durra  task  description.  The  task  producer  has  one  out¬ 
put  port  for  data  of  type  message.  It  is  intended  to  run  on  a  Sun4  processor,  and  its  implemen¬ 
tation  is  the  Ada  procedure  “producer"  in  the  library  “/usr/durra/srclib”. 


'bask  producer 
ports 

output  :  out  message; 
attributes 
processor  =  ■'sun4"; 
procedure_name  =  "producer"; 
library  =  "/usr/durra/srclib"; 
end  producer; 

Figure  2-2:  A  Primitive  Durra  Task  Description 


A  channel  description  is  always  primitive  and  is  associated  with  a  specific  Ada  package  that 
implements  it.  Channels  are  intermediary  processes  which  control  the  flow  of  data  between 
user  processes.  Channel  implementations  for  many  frequently  used  communication  disci¬ 
plines  are  provided  as  part  of  the  Durra  support  environment.  These  include  FIFO  and  priority 
queue,  broadcast,  and  merge,  among  others. 

Both  task  and  channel  descriptions  may  be  parameterized  to  allow  for  more  flexible  use  of 
components.  For  example,  one  instance  of  a  broadcast  channel  may  be  defined  to  have  3  out¬ 
put  ports  and  another  instance  to  have  10  output  ports.  Figure  2-3  contains  descriptions  of  a 
generic  channel  {fifo)  and  a  generic  task  {consumei).  Each  has  a  formal  parameter  that  deter¬ 
mines  the  data  type  of  messages  it  can  handle.  The  buffer_size  parameter  for  the  fifo  channel 
specifies  the  number  of  messages  that  can  be  buffered  by  each  input  port  of  the  channel.  The 
code  parameter  for  the  consumer  task  specifies  the  Ada  unit  that  implements  the  task  for  the 
given  data  type.  Parameter  values  are  supplied  by  task/channel  selections.  Selections  are 
templates  (identical  to  primitive  description  templates)  that  are  used  in  compound  task  de¬ 
scriptions  to  select  lower  level  components  with  the  desired  properties. 

A  compound  task  description  must  include  additional  information  about  its  structure.  Its  com¬ 
ponent  processes  and  links  are  defined  in  its  components  section  (see  Figure  2-1)  and  the 
manner  in  which  they  are  logically  connected  (which  may  vary  dynamically)  is  specified  in  its 
sfrucfures  section.  If  the  structure  of  the  compound  task  is  allowed  to  vary,  then  there  must  be 
a  reconfigurations  section  that  describes  a  set  of  structural  changes  and  the  conditions  under 
which  the  changes  will  occur.  The  clusters  section  specifies  the  physical  grouping  of  compo¬ 
nents  into  executable  images,  which  may  well  be  orthogonal  to  the  logical  connections  de¬ 
scribed  in  the  structures  section. 

Figure  2-4  is  an  example  of  a  compound  task  description.  The  task  name  consumer2^Nas  cho¬ 
sen  to  avoid  confusion  in  this  presentation;  however,  we  could  have  overloaded  the  name  con¬ 
sumer  from  Figure  2-3  without  conflict  since  the  two  tasks  have  different  parameter  and  port 
profiles.  Con»‘umer2  defines  two  internal  processes,  each  of  which  is  an  instance  of  the  previ¬ 
ously  defined  consumer.  The  process  declarations  in  the  components  section  are  examples 
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channel  fifo(msg_type:  identifier, buffer_size :  integer) 

ports 

input:  in  msg_type; 
output:  out  msg_type; 
attributes 
processor  =  "sun4"; 
bound  =  buffer_si2e; 
pac)cage_name  =  "f  ifo_channel"; 
library  =  "/usr/durra/channels"; 
end  £i£o; 

task  consumer  {msg_type: identifier, code:  string) 

ports 

input:  in  msg_type; 
attributes 
processor  =  "sun4"; 
procedure_name  =  code; 
library  =  "/usr/durra/srclib"; 
end  consumer; 

Figure  2-3:  Generic  Channel  and  Task  Descriptions 


task  consumer2 
ports 

ini:  in  byte; 
in2:  in  scalar; 

con^nents 

cl:  task  consumer  (byte,  ''byte_consumer") ; 
c2 :  task  consumer (scalar,  "scalar_consumer") ; 
structure 
LI :  begin 

baseline  cl,  c2; 
bind  ini  *•  cl. input, 
in2  -  c2 . input ; 

end  LI; 
end  consumer2; 

Figure  2-4:  A  Compound  Task  Description 


of  task  selections  that  supply  arguments  to  bind  values  to  the  formal  parameters  of  the  con¬ 
sumer  task  description.  The  structure  section  in  Figure  2-4  is  very  simple.  In  Durra,  the  struc¬ 
ture  of  an  application  is  described  as  a  collection  of  labelled  configuration  levels,  which  may 
be  either  nested  or  independent.  There  is  only  one  configuration  level  (LI)  in  this  application 


description.  The  baseline  statement  defines  which  processes  and  links  are  active  at  a  given 
level.  The  b/nof  statement  defines  a  binding  between  the  external  ports  presented  by  the  inter¬ 
face  of  consumer^  and  the  ports  of  the  internal  consumer  processes.  Since  the  internal  pro¬ 
cesses  do  not  communicate  between  themselves,  no  link  declarations  are  required. 
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In  Figure  2-5  we  provide  a  Durra  description  of  the  classic  producer-consumer  problem  as  an 
example  of  a  compound  task  description  which  also  happens  to  be  an  application  description. 
The  building  blocks  for  the  task  producer_consumer are  the  primitive  components  identified  in 
Figure  2-2  and  Figure  2-3.  Since  this  is  a  top-level  description,  there  are  no  external  ports  to 


task  producer_consumer 
cotsponents 
p:  task  producer ; 

c:  task  consumer  (message,  ''message_consumer")  ; 
buffer:  channel  fifo (message, 10) ; 

structure 
LI :  begin 

baseline  p,  c,  buffer; 
buffer:  p. output  »  c. input; 
end  Ll; 
clusters 
cll  :  p,  buffer; 
cl2  :  c; 

end  producer_consumer ; 

Figure  2-5:  A  Producer-Consumer  Application  Description 


bind,  but  we  must  establish  the  connections  between  the  processes  that  are  defined  internally. 
Connections  are  expressed  in  terms  of  the  link  implementing  the  connection.  Thus,  the  link 
buffer  connects  the  port  p.oufpuf  to  the  port  c.input  The  Duna  compiler  ensures  that  all  ports 
are  connected  and  that  they  are  connected  to  ports  of  the  proper  data  type  and  direction. 

The  Durra  programmer  specifies  the  distribution  of  application  components  by  assigning  them 
to  virtual  nodes  called  clusters.  The  clusters  section  of  the  description  specifies  that  process 
pand  link  Puffer  will  be  physically  grouped  together  at  runtime,  but  process  cwill  be  linked  into 
a  separate  executable  program.  This  concept  will  be  discussed  in  more  detail  in  Section  2.2.2. 

We  require  a  more  complex  application  description  in  order  to  demonstrate  Durra's  ability  to 
express  dynamic  reconfiguration  requirements.Figure  2-6  is  an  extension  of  the  description  in 
Figure  2-5.  Two  new  components  have  been  added;  an  instance  of  consumer2  and  an  in¬ 
stance  of  a  channel  which  implements  a  deal-by-type  discipline.  We  omit  the  description  of 
deal_bt_channel  here  to  conserve  space.  This  channel  accepts  input  of  a  generic  type  and 
deals  the  input  to  a  receiver  requesting  that  type  of  data.  The  sfrucfures  section  in  this  example 
has  been  expanded  to  include  a  second  configuration  level,  L2,  which  is  nested  within  level 
LI.  This  level  incorporates  the  two  new  components,  c2and  dealer,  and  excludes  two  of  the 
components  from  LI,  c and  buffer.  Since  process  p  is  not  explicitly  excluded  from  the  nested 
configuration  description,  it  survives  into  the  new  configuration.  The  portp.ouputis  reconnect¬ 
ed  to  link  dealer aT\di  the  two  input  ports  of  c2are  associated  with  the  two  output  ports  of  dealer. 
Note  that  this  is  not  a  data  type  conflict  since  the  ports  of  dealer  are  defined  to  be  of  type  mes¬ 
sage,  which  is  the  union  type  encompassing  the  types  byte  and  scalar,  the  types  of  ports 
c2.in1  and  c2.in2,  respectively. 
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task  dynamic_producer_consumer 
components 
p:  task  producer; 

c:  task  consumer  (message,  ''message_consumer")  ; 

c2 :  task  consumerZ ; 

buffer:  chaxmel  fifo (message,  10); 

dealer:  channel  deal_bt_channel (2, message) ; 

structure 
LI:  begin 

baseline  p,  c,  buffer; 
buffer:  p. output  »  c. input; 

L2 :  begin 

Include  dealer,  c2; 
exclude  c,  buffer; 

dealer:  p. output  »  c2.ini,  c2.in2; 
end  L2; 
end  LI; 

reconfigurations 
enter  ->  LI; 

LI  =>  L2  when  signal (c,  1); 

clusters 

cll  :  p,  buffer,  dealer; 
cl2  :  c,  c2; 

end  dynamic_producer_consumer; 


Figure  2*6:  A  Producer-Consumer  Application  Description 
Featuring  Dynamic  Reconfiguration 


The  reconfigurations  section  of  the  dynamic _producer_consumer  appWcation  description  pre¬ 
scribes  the  conditions  under  which  the  configurations  specified  in  the  structures  section  shall 
be  entered.  Transition  from  one  configuration  to  another  is  indicated  by  a  configuration  name 
pair  on  opposite  sides  of  an  arrow  operator.  When  the  appiication  is  in  the  configuration  on  the 
left-hand  side  of  the  arrow,  the  application  is  eligible  to  reconfigure  to  the  configuration  on  the 
right-hand  side  of  the  arrow.  A  condition  is  usually  associated  with  the  transition,  as  in  the  tran¬ 
sition  from  LHoL2in  Figure  2-6.  In  this  particular  case,  the  transition  will  occur  when  the  Durra 
runtime  receives  a  signal  {see  Section  2.3.4)  from  process  c.  Durra  assigns  no  semantic  con¬ 
tent  to  particular  signal  values;  the  interpretation  of  such  signals  is  a  function  of  the  application 
description.  The  transition  to  configuration  L/  is  a  special  case-  Lf  is  to  be  entered  uncondi¬ 
tionally  at  application  start-up. 


2.2  The  Durra  Application  Development  Support  Environment 

2.2.1  Compilation  and  Libraries 

Compiled  Durra  descriptions  are  maintained  in  libraries  in  an  intermediate  attributed  syntax 
tree  form.  A  Durra  library  may  have  multipie  ancestor  Durra  libraries  from  which  previousiy 
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compiled  descriptions  are  inherited.  A  library  manager  tool  is  used  to  create  and  manipulate 
these  libraries. 

Compilation  of  a  primitive  task/channel  description  results  in  a  library  entry  which  contains  a 
reference  to  the  Ada  unit  that  is  specified  as  the  implementation  of  the  description.  For  a  com¬ 
pound  Durra  task  description,  the  compiler  uses  the  information  provided  in  each  task  or  chan¬ 
nel  selection  to  pick  a  component  description  that  satisfies  the  selection  requirements  from  a 
Durra  library.  If  more  than  one  component  satisfies  the  requirements,  the  compiler  picks  the 
one  most  recently  entered  in  the  library  (and  warns  the  user  about  the  ambiguity).  The  com¬ 
pound  description  is  then  entered  in  the  library  with  pointers  to  the  library  entries  for  its  com¬ 
ponent  descriptions.  Figure  2-7  shows  graphically  the  relationships  between  the  tools,  librar¬ 
ies,  and  environment  described  here  and  in  the  following  sections. 

2.2.2  Code  Generation 

If  the  compound  description  is  a  complete  application  description,  then  the  Durra  compiler  can 
generate  an  Ada  package  body  for  each  cluster  defined  in  the  application.  The  package  body 
imports  the  implementations  of  the  components  assigned  to  the  cluster,  creates  Ada  tasks  to 
serve  as  threads  for  the  implementations,  generates  code  to  evaluate  reconfiguration  condi¬ 
tions  (if  any  are  specified),  and  defines  an  Ada  task  that  modifies  the  cluster  structure  as  re¬ 
quired.  All  these  activities  are  specific  to  the  cluster  for  which  the  package  body  is  generated. 
The  package  body  also  defines  a  set  of  tables,  common  to  all  clusters  in  the  application,  that 
describe  the  complete  application  structure.  A  hardware  configuration  table,  which  defines  the 
environment  in  which  the  distributed  application  will  run,  is  optionally  included,  (if  not  included 
here,  it  must  be  specified  at  runtime.)  As  part  of  the  support  environment,  we  provide  a  set  of 
runtime  support  packages  that  are  used  by  all  clusters.  These  support  packages,  the  cluster- 
specific  package  body,  and  a  driver  subprogram  are  combined  into  a  single  Ada  program  that 
implements  the  cluster. 

2.2.3  Support  for  Prototyping  Applications 

In  general,  the  Ada  implementation  associated  with  a  Durra  task  description  will  be  hand-cod¬ 
ed.  However,  for  prototyping  purposes,  we  provide  two  tools  that  interpret  a  particular  type  of 
behavioral  specification  called  timing  expressions.  Timing  expressions  specify  the  duration  of 
and  intervals  between  port  operations  that  the  finished  component  is  expected  to  demon¬ 
strate.  One  of  the  tools  is  an  emulator  that  mimics  any  such  specification;  the  other  generates 
an  Ada  procedure  that  mimics  a  specific  timing  specification.  The  emulator  or  the  generated 
procedure  can  be  specified  as  the  "implementation”  of  the  component  and  imported  by  a  clus¬ 
ter  like  any  other  user  procedure. 

We  anticipate  the  development  of  additional  tools  to  support  emulation  or  code  generation 
from  other  types  of  formal  behavioral  specification.  We  are  currently  working  with  Hughes  Air¬ 
craft  Company  to  develop  a  generator  for  a  language  based  on  restricted  activity  and  data 
graphs  [2].  These  graphs  may  be  used  to  define  the  flow  of  control  and  data  within  a  Durra 
task  as  well  as  its  logical,  timing,  and  resource  constraints.  The  Specification  Methodology  for 
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Durra  Libraries 

Assoc. 

Ada  Libraries 

-  Task  descriptions 

»#^Task  implementations 

-  Appl.  descriptions 

■ 

-  Generated  tables 

-  Runtime  support 

Figure  2-7:  Application  Development  Scenario 


Adaptive  Real-Time  Systems  (SMARTS)  describes  how  these  graphs  may  be  used  in  conjunc¬ 
tion  with  the  Durra  language  to  specify  the  software  architecture  of  highly  adaptive  real-time 
systems.  In  particular,  this  methodology  defines  a  strategy  for  implementing  dynamic  task  pri¬ 
orities  using  the  facilities  of  the  Durra  language. 
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2.2.4  Version  Control 

We  rely  on  vendor-supplied  Ada  library  management  tools  to  ensure  version  control  for  the 
Ada  implementations  associated  with  the  Durra  components.  Since  we  are  working  in  a  Unix 
environment,  we  support  version  control  of  Durra  application  descriptions  through  automatic 
generation  of  a  “make”  file  for  each  application.  This  is  made  possible  by  description  depen¬ 
dency  information  maintained  in  the  Durra  libraries.  The  “make”  file  also  coordinates  the  two 
control  activities,  ensuring  that  regeneration  of  the  clusters  due  to  changes  in  the  Durra  appli¬ 
cation  description  always  uses  the  appropriate  Ada  units. 

2.3  The  Durra  Runtime  Environment 

The  Durra  runtime  environment: 

•  Establishes  communications  between  clusters. 

•  Starts  and  terminates  Durra  processes  and  links. 

•  Transports  data  between  Durra  processes  and  links. 

•  Evaluates  reconfiguration  conditions. 

•  Performs  reconfigurations. 

The  Durra  runtime  has  no  responsibility  for  scheduling  Durra  processes  and  links  other  than 
starting  and  terminating  them.  Since  they  are  implemented  by  Ada  tasks,  they  are  scheduled 
by  the  Ada  runtime  and,  where  applicable,  the  host  operating  system  scheduler.  The  priority 
of  a  Durra  process  can  be  passed  to  the  Ada  mntime  via  a  “priority”  attribute  in  the  task  de¬ 
scription. 

2.3.1  Model  of  Interprocess  Communication 

Durra  implements  a  buffered  message  passing  model  of  Interprocess  communication.  Recall 
from  Section  2.1  that  Durra  channels  may  have  a  “bound”  attribute.  The  value  of  this  attribute 
determines  the  size  (in  number  of  messages)  of  the  buffer  associated  with  each  input  port  of 
the  channel.  When  a  producer  process  attempts  to  send  data  to  a  channel,  the  producer  will 
block  (I.e.,  be  suspended)  if  the  buffer  associated  with  the  port  is  full.  Conversely,  a  consumer 
process  attempting  to  read  data  from  a  channel  will  block  if  the  buffer  is  empty. 

Application  designers  thus  have  control  over  the  flow  of  data  between  processes.  Setting  the 
buffer  bound  to  zero  forces  synchronous  communication,  since  either  process  will  block  until 
the  other  arrives.  For  practical  purposes,  one  can  achieve  asynchronous  communication  by 
setting  the  bound  to  a  very  large  number. 

It  should  be  noted  that  a  Durra  process  may  have  additional  input/output  capabilities  beyond 
its  Durra  ports.  An  example  is  reading  data  from  a  file;  this  can  be  modelled  with  a  Durra  chan¬ 
nel,  but  it  is  not  strictly  necessary. 
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2.3.2  The  Durra  Runtime  Interface 


An  Ada  procedure  that  implements  a  Durra  task  accesses  Durra  runtime  services  via  the 
Durrajnterface  package.  Figure  2-8  lists  the  services  available  to  the  Ada  programmer.  A  pro- 


Flnlsh 

—  Inform  the  Durra  runtime  that  the  process  is  preparing  to  terminate. 

Get_J^plicatlon_Time 

—  Get  elapsed  time  since  this  application  entered  its  initial  configuration . 

Get_Attxlbute 

—  Get  value  of  an  attribute  defined  in  the  Durra  description  of  this  process. 

Get_Port 

—  Get  data  from  a  Durra  port. 

Get_PortID 

—  Obtains  a  handle  for  a  Durra  port  name. 

G«t_Pxocea8_Tixae 

—  Get  elapsed  time  since  this  process  started. 

G«t_TypeID 

—  Obtains  a  handle  for  a  Durra  type  name. 

Initialize 

—  Obtains  a  Process_ID,  a  handle  for  further  runtime  service  requests. 

Ral8e_Slgnal 

—  Send  a  signal  to  the  runtime. 

Safe 

—  Indicate  that  it  is  safe  to  perform  a  reconfiguration  involving 

—  this  process. 

Send_Pozt 

—  Send  data  to  a  Durra  port. 

Te8t_Input_Port 

—  Returns  the  number  of  messages  now  available  on  this  port,  as  well  as 

—  the  type  and  size  of  the  next  message  that  will  be  delivered. 
TeatjOutput_Port 

—  Aeturne  the  number  of  messages  that  the  process  is  guaranteed  to  be 

—  able  to  send  without  blocking. 

Figure  2-8:  Durra  Runtime  Services 


cedure  will  typically  begin  by  calling  Initialize  and  then  make  one  or  more  calls  to  Get_PortlD 
and  Get_TypelD.  This  establishes  the  presence  of  the  process  with  the  runtime  and  provides 
the  process  with  the  Durra  object  handles  necessary  for  interprocess  communication.  It  can 
then  use  the  Send_Portajn6  Get_Port  caWs  to  transmit  and  receive  data.  The  TestJnputJPort 
and  Test_Ouput_Portca!As  may  be  used  to  test  the  status  of  the  port  in  order  to  avoid  blocking 
when  sending  and/or  receiving.  When  the  procedure  has  completed  its  work  it  must  call  Finish', 
failure  to  do  so  causes  unpredictable  application  behavior. 

The  implementation  of  the  port-related  calls  varies  depending  on  the  distribution  of  the  pro¬ 
cesses  and  the  link  involved  in  the  transaction.  In  Figure  2-9  we  see  an  example  of  two  differ¬ 
ent  kinds  of  interprocess  communication.  The  gray  boxes  in  the  figure  represent  Ada  tasks.  In 
Cluster  1 ,  user  processes  P  and  Q  are  communicating  through  link  A.  Process  P  is  also  com¬ 
municating  with  remote  user  process  R  through  remote  link  B.  Links  are  passive  tasks;  they 
are  servers  for  requests  from  processes.  So  in  order  for  process  P  to  send  data  to  process  Q, 
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|||l'*  Interprocess  Communication  Ada  rendezvous 


Figure  2-9:  Interprocess  Communication  In  the  Durra  Runtime 


both  must  rendezvous  with  link  A.  If  P  is  blocked  while  attempting  to  send  data,  then  its  ren¬ 
dezvous  must  be  ended  to  allow  link  A  to  process  other  requests.  Process  P  must  then  issue 
a  second  entry  call  to  wait  for  notification  that  the  buffer  is  no  longer  full.  Similarly,  process  Q 
will  block  if  the  buffer  is  empty.  The  rendezvous  must  be  released  and  process  Q  must  issue 
a  second  entry  call  and  wait  for  data  to  arrive.  So  if  all  three  processes  are  local,  a  minimum 
of  two  and  a  maximum  of  three  rendezvous  are  required  to  transfer  the  data.  For  non-local 
communications,  each  cluster  uses  a  pair  of  Ada  tasks,  f?emofe_Oi/f  and  Remotejn.  In  order 
for  process  P  to  send  data  to  process  R  through  link  B,  a  total  of  six  or  seven  rendezvous  are 
required,  as  well  as  two  network  messages.  Although  the  work  load  is  distributed,  this  is  obvi¬ 
ously  a  high  overhead  for  message  delivery  and  we  are  currently  examining  ways  to  reduce  it. 

2.3.3  Clusters 

The  result  of  the  compilation  process  described  earlier  is  an  executable  program  for  each  clus¬ 
ter  named  in  the  application  description.  A  wide  range  of  distribution  choices  is  available  to  the 
programmer,  from  assignment  of  all  components  to  a  single  cluster  (the  degenerate  case,  in 
which  the  application  is  not  actually  distributed),  to  assignment  of  a  single  component  per  clus¬ 
ter.  The  clusters  themselves  may  then  be  assigned  to  processors  in  various  combinations 
ranging  from  all  on  one  processor  (in  multiprocessing  environments)  to  one  cluster  per  proces¬ 
sor. 

To  avoid  starting  all  the  clusters  of  a  Durra  application  independentiy,  a  tool  external  to  the 
Durra  runtime  may  be  required.  In  the  UNIX  environment,  we  use  a  program  called  the 
Durra_Launcher\o  start  all  clusters  except  the  first,  which  is  started  by  hand.  This  cluster  is 
considered  the  master,  a  first  among  equals.  The  master  cluster  is  then  responsible  for  in¬ 
structing  the  Durra_Launcher\o  start  all  the  other  clusters.  Once  started,  a  cluster  attempts  to 
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establish  communications  with  the  other  clusters  in  the  configuration  by  means  of  an  estab¬ 
lished  protocol. 

Mastership  is  a  dynamic  status  that  may  be  passed  among  clusters  as  the  structure  of  an  ap¬ 
plication  evolves.  The  master  differs  from  the  other  clusters  primarily  in  its  responsibility  for 
control  of  the  reconfiguration  process.  There  are  two  reasons  for  the  designation  of  a  master. 
The  first  is  that  a  reconfiguration  condition  expression  may  be  composed  of  subconditions 
which  are  detected  in  separate  clusters.  A  logical  conjunction  of  these  subconditions  must  be 
evaluated  In  either  a  single  cluster  or  in  all  clusters.  We  have  chosen  a  single  master  cluster 
since  this  requires  less  intercluster  communication.  For  example,  assuming  the  structure 
shown  in  Figure  2-9,  the  subexpressions  in  the  condition  “signal(P,1)  and  signal(R,2)'‘  would 
be  detected  in  Cluster  1  and  Cluster  2  independently.  The  evaluation  of  the  complete  expres¬ 
sion  would  be  performed  in  the  cluster  designated  as  master.  The  master  should  therefore  be 
designated  as  the  cluster  where  reconfiguration  condition  evaluation  can  be  done  most  effi¬ 
ciently  (locally).  This  may  vary  at  different  configuration  levels,  so  the  master  designation  is 
assignable.  Once  an  entire  reconfiguration  condition  evaluates  to  true,  the  reconfiguration 
must  be  initiated.  That  is  the  second  reason  for  the  single  master  approach.  One  cluster  must 
control  the  initiation  of  reconfigurations  in  order  to  avoid  concurrent  incompatible  reconfigura¬ 
tions.  The  master  cluster  notifies  the  other  clusters  when  a  reconfiguration  is  beginning.  Then 
the  reconfiguration  is  carried  out  in  parallel  by  the  individual  clusters,  with  each  cluster  respon¬ 
sible  for  the  changes  that  affect  its  local  component  set.  In  case  of  failure  of  the  master  cluster, 
the  surviving  clusters  must  agree  on  a  new  master.  User  components  in  the  failed  cluster  can 
be  restarted  on  a  new  cluster,  but  their  computation  states  will  be  lost  unless  the  application 
has  provided  some  means  of  recovering  them. 

As  mentioned  earlier,  the  hardware  configuration  on  which  the  distributed  application  will  run 
must  be  specified  either  at  compile  time  or  at  runtime.  The  hardware  configuration  information 
is  contained  in  a  file.  If  this  file  is  supplied  to  the  Durra  compiler  when  Ada  code  is  generated, 
then  the  information  can  be  included  in  the  cluster-specific  tables  being  generated.  If  supplied 
at  runtime,  the  file  must  be  read  and  the  tables  modified.  In  either  case,  the  specification  of 
hardware  resources  must  be  complete;  Durra  does  not  support  dynamic  reconfiguration  of  the 
application  platform.  Hardware  specification  at  compile  time  decreases  cluster  Initialization 
overhead  at  the  cost  of  experimental  flexibility.  The  reverse  is  true  of  runtime  specification. 
Since  the  runtime  specification  overhead  is  small  and  the  cost  of  code  regeneration  and 
recompilation  can  be  high,  the  likely  best  choice  is  to  use  runtime  specification  during  devel¬ 
opment  or  experimentation  and  compile  time  specification  for  a  production  system. 

2.3.4  Dynamic  Reconfiguration 

Dynamic  reconfiguration  of  an  application  is  the  modification  of  its  structure  while  the  applica¬ 
tion  is  running.  This  may  involve  addition  or  subtraction  of  processes,  or  simply  redistribution 
of  the  existing  processes.  Reconfiguration  in  the  Durra  world  does  not  involve  process  migra¬ 
tion.  A  task  that  is  expected  to  run  in  two  different  clusters  during  the  lifetime  of  an  application 
must  be  declared  as  two  separate  process  components. 
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A  Durra  reconfiguration  condition  is  a  Boolean  expression  involving  information  available  to 
the  clusters  at  runtime  as  well  as  signals  from  application  processes.  If  reconfiguration  condi¬ 
tions  are  present  in  the  application  description,  then  part  of  the  code  generated  for  each  cluster 
is  a  case  statement  that  allows  evaluation  of  the  conditions  enabled  at  each  configuration  lev¬ 
el.  Conditions  based  on  elapsed  time  are  implemented  as  delay  statements:  when  the  delay 
expires,  the  condition  is  true.  When  an  expression  evaluates  to  true,  the  case  statement  pre¬ 
scribes  an  entry  call  to  the  State_Changer  lask,  which  is  also  generated  by  the  Durra  compiler. 
The  master  cluster  passes  the  information  to  the  other  clusters.  In  each  cluster,  State_Chang- 
er  carries  out  the  reconfiguration,  starting  new  tasks  and  terminating  old  ones  as  required  to 
transition  to  the  new  configuration. 

2.4  Application  Issues 

2.4.1  Programming  Language  Restrictions 

Most  Durra  tasks  will  be  implemented  in  the  Ada  programming  language.  In  some  Ada  envi¬ 
ronments,  one  may  be  able  to  incorporate  procedures  written  in  other  languages  as  Durra 
tasks.  To  do  this,  one  has  to  have  an  environment  that  allows  for  Ada  to  interface  to  the  other 
language  and  that  also  provides  a  mechanism  to  call  Ada  subprograms  from  the  other  lan¬ 
guage  so  that  the  foreign  procedure  can  call  Durra  runtime  services. 

In  our  original  implementation  of  Durra,  each  user  component  was  mapped  onto  an  operating 
system  process.  The  Durra  runtime  support  for  each  processor  was  also  in  a  separate  pro¬ 
cess.  An  advantage  of  this  approach  is  the  ability  to  support  mixed-language  applications  eas¬ 
ily;  one  oniy  needs  an  implementation  of  the  Durra  runtime  interface  for  each  language  to  be 
used.  There  are  several  disadvantages  associated  with  this  approach,  though.  One  is  the  cost 
of  interprocess  communication.  In  applications  where  multiple  Durra  processes  are  assigned 
to  a  single  processor,  it  is  more  efficient  to  model  the  concurrency  using  Ada  tasking  within  a 
single  operating  system  process.  The  original  Durra  runtime  was  also  less  portable;  since  it 
assumed  a  multiprocessing  operating  system  environment,  it  could  not  be  ported  to  bare  ma¬ 
chine  targets.  Because  we  felt  these  disadvantages  outweighed  the  vaiue  of  language  inde¬ 
pendence,  we  made  a  conscious  decision  to  provide  only  minimal  support  for  mixed  language 
Durra  applications. 

2.4.2  Support  for  Heterogenous  Machine  Architectures 

Durra  allows  distribution  of  a  single  application  across  some  number  of  physical  processors. 
There  is  no  requirement  that  these  processors  be  homogeneous.  We  have  run  small  experi¬ 
mental  applications  that  were  distributed  across  Sun4,  Sun3,  VAX/ULTRIX,  and  VAXA/MS 
hosts  in  various  combinations.  Of  course,  each  processor  in  any  potential  Durra  platform  must 
have  a  validated  Ada  compiler  available.  Since  the  components  of  a  Durra  application  are 
standard  Ada  programs,  there  are  no  special  requirements  on  the  Ada  compiier  or  runtime. 
The  Durra  runtime  library  must  be  ported  to  each  target  architecture  in  the  platform  and  all  the 
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processors  must  support  a  common  communication  protocol.  We  have  used  the  TCP  protocol 
in  our  experiments  to  date. 

Data  representation  issues  are  not  addressed  by  the  Durra  runtime.  This  is  a  natural  result  of 
Durra’s  treatment  of  component  tasks  and  types  as  “black  boxes."  Durra  tasks  do  not  know 
what  happens  to  data  once  it  has  been  sent  to  a  port.  Therefore,  it  is  up  to  application  design¬ 
ers,  who  do  know  about  the  target  architectures  and  the  distribution  of  processes,  to  account 
for  required  data  representation  changes  in  their  designs.  This  can  be  done  by  either  inserting 
additional  processes  or  special  purpose  links  that  transform  the  data  as  they  transfer  it. 

2.4.3  Application  Domain  Independence 

The  Durra  language  and  runtime  environment  are  domain-independent.  They  support  the  de¬ 
velopment  of  applications  consisting  of  distributed,  message-passing  components.  The  nature 
of  the  components  and  messages  is  a  domain-specific  concern,  above  Durra  and  its  imple¬ 
mentation.  For  example,  one  could  implement  a  distributed  programming  environment  in 
which  various  tools  (compiler  phases,  library  managers,  etc.)  execute  as  cooperating  Durra 
tasks,  sending  various  kinds  of  data  structures  (annotated  syntax  trees,  module  dependency 
lists,  etc.)  through  channels  which  provide  the  appropriate  data  transformation  and  filtering  op¬ 
erations.  Both  tasks  and  channels  could  be  user  written  or  automatically  generated  by  compil¬ 
er-compilers  or  similar  tools  using  formal  language  specifications  and  interface  description 
languages  such  as  IDL[3].  These  domain-specific  tools  are  outside  the  scope  of  our  project. 
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3  Related  Work 


There  are  two  distinct  areas  of  ongoing  research  to  which  Durra  is  related.  One  is  support  for 
distribution  of  Ada  programs  in  particular.  The  other  is  programming  languages  for  the  speci¬ 
fication  and  prototyping  of  large-grained  parallel  applications  in  general. 

Numerous  projects  are  underway  to  develop  tools  and  methodologies  for  the  support  of  dis¬ 
tributed  Ada  software.  These  attempts  fall  into  two  broad  classes:  either  the  application  is  writ¬ 
ten  as  a  single  Ada  program  and  then  partitioned  for  distribution,  or  the  application  is  written 
as  multiple  programs  which  communicate  through  some  standardized  interface.  Examples  of 
the  former  include  APPL  [4],  Aspect  [5],  and  DARTS[6].  Examples  of  the  latter  include  DIA¬ 
DEM  [7]  and  DARK  [8].  Single  program  approaches  have  many  advantages,  including  com¬ 
munication  via  standard  Ada  facilities  and  type  and  consistency  checking  enforced  by  the  lan¬ 
guage.  However,  APPL  requires  extensive  compiler  support  which  makes  distribution  to  het¬ 
erogenous  processor  environments  problematic.  In  DARK  and  DIADEM,  separate  program 
components  communicate  via  a  remote  procedure  call  and  a  remote  rendezvous  mechanism, 
respectively.  DARK  does  not  provide  language  support  for  distribution  specification,  so  appli¬ 
cation  structure  is  not  separated  from  function.  The  virtual  node  approach  taken  in  DIADEM  is 
similar  to  ours,  but  DIADEM  allows  for  compile-time  checking  of  interfaces  like  single  program 
approaches.  Durra's  advantages  over  all  these  approaches  are  its  language  support  for  recon¬ 
figuration  and  component  reuse  in  multiple  application  environments,  and  its  provision  of  sig¬ 
nificant  flexibility  (via  user-defined  channels)  in  the  forms  interthread  communication  may  take 
(asynchronous  versus  synchronous,  FIFO  versus  priority  message  arrival,  etc.). 

The  three  systems  most  like  Durra  are  NAS(91,  CSLyModel  [10],  and  Conic  [1 1].  NAS,  which 
is  being  used  in  at  least  one  fielded  software  product,  is  probably  the  most  mature  technology 
in  this  arena.  Its  distributed  application  structure  model  is  very  similar  to  Durra’s.  NAS  provides 
operator  interfaces  in  support  of  performance/error  monitoring  and  operator-controlled  dynam¬ 
ic  reconfiguration.  However,  Durra's  method  of  software  architecture  specification  and  its  ap¬ 
plication  program  runtime  interface  is  simpler  than  that  of  NAS.  CSL  is  used  to  specify  appli¬ 
cation  interconnection  and  distribution  in  the  same  manner  as  Durra.  A  CSL  application  can 
incorporate  implementations  generated  by  the  Model  compiler  from  behavioral  specifications. 
CSL's  support  for  reconfiguration  and  communication  flexibility  is  limited,  though.  Conic’s  con¬ 
structive  approach  is  similar  to  Durra’s  but  since  Conic  applications  must  be  written  in  Pascal, 
their  virtual  nodes  cannot  be  multithreaded.  Unlike  Durra,  both  CSL  and  Conic  offer  graphical 
front  ends  to  their  respective  specification  languages. 

Polylith  [12]  and  Reality  [13]  are  highly  flexible  distributed  application  description  languages 
focused  on  support  for  prototyping.  Polylith  provides  a  more  flexible  approach  to  dynamic 
reconfiguration  than  Durra,  but  it  requires  user  intervention.  Polylith  modules  are  connected 
via  a  software  bus,  to  which  a  user  can  attach  new  modules  at  arbitrary  times.  A  framework 
for  application-controlled  reconfiguration  is  under  developmen^lA].  Reality  is  a  more  ambi¬ 
tious  project;  its  long-term  goals  include  facilitating  the  evolution  of  prototypes  to  production 
quality  software/hardware  systems. 
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